<h2>Why is this an issue?</h2>
<p>Good exception management is key to keeping a consistent application state in the face of errors and unexpected behaviors. However, in some cases,
the information carried by the exception is not as important as the exception bubbling up itself. In such cases, developers may want to explicitly
indicate that they have no use for the exception parameter. Java 22 introduces the unnamed variable pattern <code>_</code> which allows developers to
free the catch clause from an unnecessary exception parameter name.</p>
<h2>How to fix it</h2>
<p>Replace exception parameter name with unnamed variable pattern <code>_</code>.</p>
<h3>Code examples</h3>
<h4>Noncompliant code example</h4>
<pre data-diff-id="1" data-diff-type="noncompliant">
List&lt;String&gt; elements = // ...
int value = 0;
try {
  var elem = elements.get(idx);
  value = Integer.parseInt(elem);
} catch (NumberFormatException nfe) { // Noncompliant
  System.err.println("Wrong number format");
} catch (IndexOutOfBoundsException ioob) {  // Noncompliant
  System.err.println("No such element");
}
</pre>
<h4>Compliant solution</h4>
<pre data-diff-id="1" data-diff-type="compliant">
List&lt;String&gt; elements = // ...
int value = 0;
try {
  var elem = elements.get(idx);
  value = Integer.parseInt(elem);
} catch (NumberFormatException _) {
  System.err.println("Wrong number format");
} catch (IndexOutOfBoundsException _) {
  System.err.println("No such element");
}
</pre>
<h2>Resources</h2>
<h3>Documentation</h3>
<ul>
  <li> OpenJDK - <a href="https://openjdk.org/jeps/456">JEP 456: Unnamed Variables &amp; Patterns</a> </li>
</ul>

